Software clients operating on or in conjunction with a computer system are often used to access data stored at a server with which the computer system can establish communications, such as through a local area network (LAN). In many instances, the data on the server is accessible only through a particular protocol, which in turn tends to limit a user to a particular client. Similarly, a particular type of client is typically configurable to operate with only certain types of servers or protocols. In an e-mail system, for example, in which users have associated mailboxes on a mail server, a particular protocol and often a particular messaging client is required for e-mail access. There is no single standard method for accessing e-mail stored on a server. Instead, there are several incompatible protocols defined by various vendors and standards bodies.
Each category of client accessing an application may have different capabilities and needs. For example, a POP client accessing a mail service may require a list of unique identifiers (UIDs) from the server, whereas a WAP client may require not only the UIDs, but also a subject. A desktop browser client may require not only UID and subject, but also information regarding message origination, date, importance, etc. When developing a service that can handle all of these needs, it would a more efficient use of bandwidth and processing power, both on the server and on a target data system such as a mail store, if only the necessary attributes were requested and returned whenever possible.
Another problem is that each of these clients may require slightly different behavior in response to a request. For example, a POP client might request that a message on the server be deleted, however, instead of removing it at the time of the request, the service has to wait until the POP client issues the QUIT command. For a WAP client, on the other hand, the message should be deleted immediately in response to a delete request.
A further problem that frequently occurs when building an application has to do with memory consumption and application performance. To improve performance, it often makes sense to cache results from a data store to more quickly respond to a follow-on request from the client. If data is stored in memory, the application can quickly use up all available memory. Even caching the data on disk can lead to disk space problems.
It is also possible to access multiple data sources that have different capabilities or support different mechanisms for querying information. In this case, code can quickly become convoluted when attempting to manage multiple and different request types.
Various prior art approaches have been developed for providing communications between systems and devices using different operating protocols. One such approach is set forth in U.S. Pat. No. 6,615,212 to Dutta et al., in which a transcoding proxy server receives a request for content from a client machine. The transcoding proxy server retrieves the content from an originating server. The retrieved content is provided in a first format type. In response to a determination that an increase in efficiency would be obtained by allowing the client to process the content in the first format type prior to transcoding the content into a second format type, the transcoding proxy server sends the content to the client in the first format type.
Furthermore, in response to a determination that the client does not have content processing software for processing the content in the first format, the transcoding proxy server sends content processing software for the first format type along with the content in the first format type to the client. The transcoding proxy server then transcodes the content from the first format type into the second format type and sends the content in the second format to the client.
Despite such prior art approaches, further protocol translation and/or conversion functionality may be desirable in certain applications.